A virtual machine operating system is well known today, and includes a common base portion and separate user portions formed by the common base portion. In an IBM z/VM operating system, the common base portion is called the “Control Program” or “CP” and each user portion is called a “virtual machine” or “guest”. A virtual machine or guest is a virtual sharing/partitioning of real resources such as real memory, CPU and I/O. Examples of I/O devices are DASD, network cards, printers and displays. A guest operating system executes/runs on each virtual machine, and one or more applications run on the guest operating system. Each application and guest operating system behave as if they are running on their own private, real computer.
Typically, each virtual machine is allocated a finite amount of resources, such as private virtual memory, real CPU and real I/O. The amounts allocated are intended to accommodate maximum needs of the virtual machine during most operating conditions. However, during operation of the virtual machine, the virtual machine has varying needs for each of these resources. During some periods, the virtual machine may be executing applications requiring complex arithmetic computations which are CPU intensive and during other periods the virtual machine may be executing applications such as data backup applications which hardly use the CPU. Likewise, during some periods the virtual machine may be executing applications such as data base searching, reading and writing applications which require much private memory and during other periods the virtual machine may be executing applications such as text editing applications which require little private memory. Likewise, during some periods the virtual machine may be executing applications such as data backup applications which require substantial I/O activity and during other periods the virtual machine may be executing applications such as arithmetic computation applications which require little I/O activity. During some of the periods of operation, the virtual machine may need more of a virtual resource than has been allocated, in which case the finite virtual resource allocation may constrain the operation of the virtual machine. During other periods of operation, the virtual machine does not utilize its full allocation of one or more virtual resources, so these virtual resources may be wasted in the sense that another virtual machine could have used the excess allocation.
The following is an example of how a known virtual machine utilizes its CPU to perform work items. Each virtual machine has its own dispatch function which consists of its synchronization or lock function, work queue assignment function, work scheduler and associated work queue of work items or tasks assigned by and to the virtual machine. The synchronization or lock function, work queue assignment function, work scheduler and the work queue are all private to the virtual machine. The synchronization or lock function manages locks for a work queue to control which work items must run sequentially and which tasks can run in parallel. A work queue assignment function is a program function within the virtual machine which adds work items to the work queue of the virtual machine when generated by the virtual machine. The work items are added to the queue at a position based on an assignment algorithm. The assignment algorithm may consider such factors as relative priority level of each work item and the order in which work items were created, i.e. first in first out. Each work item on the queue includes information indicating its type, and therefore, which function within the virtual machine is best suited to handle it. A “work scheduler” is a program function which schedules each of the work items on its queue for execution. Generally, the work scheduler removes work items from an end of the queue. The work scheduler passes the work items to the appropriate function within the virtual machine for execution by the virtual CPU. If the work items on the work queue are CPU intensive and the allocation of virtual CPU is inadequate, the work queue may grow in length as the existing work items on the queue are removed more slowly than new work items are added to the queue. In such a case, the virtual machine will fall behind in its work.
It was also known for multiple virtual machines to share a work queue to distribute the work items amongst the virtual machines and their respective shares of real CPUs. A server virtual machine was utilized for the purpose of “hosting” this shared work queue for the other, “working” virtual machines. The shared work queue resides in memory private to the server virtual machine. When a working virtual machine creates a new work item, and the work queue assignment function for this working virtual machine decides to send this new work item to the server virtual machine, it uses a communication protocol (e.g. TCP/IP) and a virtual I/O device driver to send that work item to this server virtual machine. Then, the server virtual machine places the new work item on the shared work queue in an order determined by the server virtual machine. When the virtual CPU within a working virtual machine is available to execute a work item on the shared work queue, the work scheduler within this working virtual machine uses a communication protocol and virtual I/O device driver to make that request to the server virtual machine. In response, the server virtual machine uses a communication protocol to send a work item to the working virtual machine that made the request. While this arrangement provides a shared work queue, it requires a high overhead communication protocol to both send a work item to the work queue and obtain a work item from the work queue. Furthermore, the server virtual machine attempts to balance the load among the working virtual machines by monitoring the working virtual machines and estimating which working virtual machine will be able to handle the work item most expeditiously. The server virtual machine must also be able to re-balance the load among working virtual machines when working virtual machines are dynamically added and/or deleted. Still further, the server virtual machine must synchronize the work items as determined by its private synchronization function. All these server virtual machine functions require considerable communication and “overhead” between the server virtual machine and the working virtual machines.
An object of the present invention is to provide functionality in a virtual machine operating system which helps to match the needs of the application(s) running on each virtual machine to the available resources.
Another object of the present invention is to provide functionality in a virtual machine operating system of the foregoing type which operates dynamically to help match the changing needs of the application(s) running on each virtual machine to the available resources.
Another object of the present invention is to provide functionality of the foregoing type which also considers limits set by the system administrator for resources available to the application(s) running on each virtual machine.